---
theme: gaia
_class: lead
paginate: true
backgroundColor: #fff
marp: true
math: mathjax
---

<style>
img[alt~="center"] {
  display: block;
  margin: 0 auto;
}
code {
    background: #000;
}
pre {
    background: #000;
}
</style>

# Автоматизация разработки и эксплуатации ПО

<style scoped>
h1 {
    font-size: 1.5rem;
}
h2 {
    font-size: 1rem;
}
</style>

![bg left:40% 80%](../images/iu5edu_logo.jpg)

## Методология, принципы, подходы и технологии DevOps

**Аладин** Дмитрий Владимирович

[iu5edu.ru/wiki/devops/](https://iu5edu.ru/wiki/devops/)

---

# План

<style scoped>
h1 {
    font-size: 1.2rem;
}
li {
    font-size: 1rem;
}
</style>

1. DevOps как методология.
2. DevOps как сочетание культурных принципов.
3. DevOps как сочетание разработки и поддержки продуктов.
4. DevOps как совместная деятельность.
5. DevOps как сочетание подходов.
6. DevOps как сочетание технологии.
7. Эволюция концепций разработки.
8. Гибкая методология разработки.
9. Agile и DevOps.

---

<style scoped>
h1 {
    font-size: 1.2rem;
}
</style>

# Сегодня в выпуске

![height:500px center](./images/kubernetes-simpsons-mem.gif)

---

# В конце выпуска

<style scoped>
h1 {
    font-size: 1.2rem;
}
</style>

![height:500px center](./images/scrum-master-mem.jpg)

---

<style scoped>
p {
    font-size: 0.8rem;
}
</style>

![height:450px center](./images/crocodile-mem.jpg)

В современном мире каждый понимает терминологию, которую рассмотрим далее, по своему, не смотря на множество трудов и устоявшихся терминов. Это не мешает людям понимать, что такое DevOps, по своему.

---

# Определение термина DevOps

<style scoped>
h1 {
    font-size: 1.1rem;
}
p {
    font-size: 0.9rem;
}
li {
    font-size: 0.9rem;
}
</style>

**DevOps** (development & operations) — методология автоматизации технологических процессов сборки, настройки и развёртывания программного обеспечения. В любом процессе разработки участвует [три команды](https://practicum.yandex.ru/blog/chto-takoe-tehnologiya-devops/):

- **Dev** — программисты, которые непосредственно пишут код;
- **QA/QC** (часто рассматривают как часть Dev) тестировщики, которые выявляют ошибки в коде, вручную или автоматически;
- **Ops** — инженеры, которые поддерживают инфраструктуру для написания кода, например сервера, а также берут уже рабочий код и запускают на реальные сервера, чтобы клиент получил доступ к сайту, сервису или приложению.

---

# Определение термина методология

<style scoped>
h1 {
    font-size: 1.2rem;
}
</style>

[**Методология**](https://old.bigenc.ru/philosophy/text/2209127) - *в узком смысле слова* – совокупность процедур, приёмов и методов науки, объединённых в **единую конструктивную программу** и служащих **средствами для постижения** того или иного объекта научного знания.

[**Методология**](https://old.bigenc.ru/philosophy/text/2209127) - *в широком смысле слова* – совокупность методов, используемых в той или иной области деятельности для реализации определённых целей.

---

[**Методология**](https://iphlib.ru/library/collection/newphilenc/document/HASH01e202fe7b591ef6cabae3e1) - тип рационально-рефлексивного сознания, направленный на изучение, совершенствование и конструирование методов в различных сферах духовной и практической деятельности.

**Методика** — это практический подход или набор инструкций, которые используются для достижения определенных целей или решения конкретных задач.

**Методология** — это более общий и философский подход к исследованию, изучению и оценке методов и процедур.

---

# DevOps как методология

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
</style>

**DevOps** — это методология взаимодействия всех участников цикла разработки и взаимная интеграция их рабочих процессов, которая помогает обеспечивать **качество продукта**. Она появилась на базе Agile в 2008 году — гибкой методологии разработки, где основной фокус на качество продукта и все, от чего это зависит.

![height:350px center](./images/agile-devops.png)

---

# В чем выражается методология DevOps

<style scoped>
h1 {
    font-size: 1.2rem;
}
li {
    font-size: 1rem;
}
p {
    font-size: 1rem;
}
</style>

**DevOps как методология** - *в широком смысле* - совокупность методов, используемых в той или иной области деятельности для достижения следующих **целей**:

- увеличение скорости разработки;
- улучшение сотрудничества и коммуникации;
- улучшение качества продукта;
- сокращение затрат и оптимизация ресурсов.

*P.S. Как эти цели достигаются мы рассматривали в предыдущих лекциях.*

---

DevOps безусловно не на 100% заимствовал все подходы из Agile, но он взял лучшее, а некоторые моменты даже преобразил.

> Это не случайность — Agile отлично работает в стартапах, маленьких командах, но на больших проектах, как правило, приводит к большим проблемам: отсрочкам запуска на месяцы и даже полному провалу.
>
> Из статьи [Жертвы Agile: почему гибкая методология разработки губит крупный бизнес и помогает малому](https://vc.ru/flood/20942-agile-victims)

*P.S. Позже обсудим проблемы Agile.*

---

# Определение терминов принцип и культурный принцип

<style scoped>
h1 {
    font-size: 1rem;
}
</style>

[**Принцип**](https://spiritual_culture.academic.ru/1769/Принцип) (лат. principium – первоначало, основа) – основополагающая, фундаментальная идея, правило поведения, следование которым помогает наилучшим образом достигать поставленных целей.

[**Принцип**](https://gufo.me/dict/bse/Принцип) - основное исходное положение какой-либо теории, учения, науки, мировоззрения, политической организации и т.д.; внутреннее убеждение человека, определяющее его отношение к действительности, нормы поведения и деятельности; основная особенность устройства какого-либо механизма, прибора.

---

[**Принцип**](https://iphlib.ru/library/collection/newphilenc/document/HASHd07841269cc1c42c74c0d0) - исходное, не требующее доказательств положение теории (то же, что аксиома или постулат); внутреннее убеждение, неизменная позиция или правило поведения (то же, что максима или заповедь).

**Культурные категории** представляют собой те различия в культурах, по которым делится весь мир, — например, различия в способах организации досуга и в отношении к труду или же различия классового, социального, полового, возрастного или профессионального характера.

**Культурные принципы** представляют собой некие теоретические положения, на основании которых сформирована данная культурная категория.

---

# DevOps как сочетание культурных принципов

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.85rem;
}
</style>

![bg right:50% 95%](./images/sysadmin-devops-mem.jpg)

**DevOps** —  это ещё и культурное явление в разработке и сочетание культурных принципов, подходов и средств. *В Agile ест*ь: аналитики (бизнес и системные), разработка, тестирование, инженеры, которые отвечают непосредственно за поддержку продакшена. *В DevOps* появляются новые роли и ответвления.

---

# Ответвления DevOps

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
li {
    font-size: 0.8rem;
}
</style>

- **Методология SRE** (site reliability engineering). Эта методология делает упор на мониторинг и на качество продукта и услуги сервиса предоставляемым клиентам компании.
- **Клауд-инженеринг** (cloud engineering). Он нацелен на работу с различными облачными решениями, как классическими облаками, так и multi-clouds и содержимого в них.
- **ChatOps**. Это подход к управлению операционными задачами и коммуникации внутри команды и организации с использованием чат-платформы и инструментов для мгновенного обмена сообщениями, а так же управлению инфраструктурой и стэком CI/CD через мессенджеры.
- **ArchOps**. Это направление фокусируется на архитектурных аспектах разработки, начиная от проработки дизайна архитектуры, заканчивая стоимостью оборудования под разрабатываемое ПО.

---

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
li {
    font-size: 0.8rem;
}
</style>

![bg left:45% 95%](./images/ops-mem.jpg)

Кажется, что

> Давайте к любому слову добавим -Ops и все будет клево!

На деле, нужно смотреть на то, как новое слово с -Ops применяется и какие смысловые нагрузки оно несет. Чаще всего это применение ранее существовавшей практики/методологии/подхода/метода в DevOps/Agile. Насколько хорошо он/она/они применены для разработки зависит от многого.

*P.S. Интересный доклад: [Dev.+Ops, или Строим идеальный процесс поставки](https://youtu.be/etwR3o1hRjY).*

---

# NoOps

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
li {
    font-size: 0.8rem;
}
</style>

![bg right:35% 100%](./images/noops-mem.jpg)

Теория **NoOps**, или "без операторов", заключается в полной автоматизации обслуживания IT проектов таким образом, что отпадает необходимость в операциях по управлению и наблюдению в процессе разработки. NoOps предполагает программную среду, в которой люди не считаются необходимыми для бесперебойной работы функций; и в результате, любая активность автоматизирована.

*P.S. Некоторые наблюдатели рассматривают NoOps как [катастрофу](http://devops.com/2015/12/01/noops-devops-disaster-waiting-happen/), которая вот-вот произойдет.*

---

# В основе DevOps лежат конфликты

<style scoped>
h1 {
    font-size: 0.9rem;
}
p {
    font-size: 0.7rem;
}
li {
    font-size: 0.7rem;
}
</style>

![bg left:40% 95%](./images/noops-managers-mem.jpeg)

- **Разработчики ПО** хотят писать код, реализовывать фичи и запускать их в инфраструктуре без проблем и не закапываясь в подробности эксплуатации.
- **Девопсеры** хотят заниматься упрощением и поддержанием стабильности продакшена, оптимизацией инфраструктуры, улучшением мониторинга и внедрением инноваций, не касаясь сервисов конечного пользователя и запросов доступа.
- **Менеджеры** хотят быстро, качественно и дешево.

Спустя десятилетия разговорный ИИ решит проблемы всех трех групп, сократив их количество 😈 Останутся только тестировщики.

---

ОПСов много, а ОПСОСы — это ОПераторы СОтовой Сети.

![height:500px center](./images/opsos-mem.jpg)

---

# DevOps как сочетание разработки и поддержки продуктов

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
li {
    font-size: 0.8rem;
}
</style>

- **Dev** — development (разработка).
- **Ops** — operation (эксплуатация).

![bg left:50% 100%](./images/dev-ops-problem-mem.jpg)

**DevOps** — это сочетание разработки и поддержки продуктов, но, в зависимости от процессов компании, это везде может выглядеть по-разному.

---

# За что могут отвечать DevOps-инженеры

<style scoped>
h1 {
    font-size: 1.2rem;
}
</style>

- за продуктивный контур;
- за все контура и стэк CI/CD;
- за всё, что связано с CI/CD и тестовые контуры.

А могут только исключительно за развитие продуктов, внедрение новых технологий и всего, что связано с CI/CD-конвейером.

Все зависит **от компании и от зрелости процессов** разработки в ней.

---

# DevOps как совместная деятельность

<style scoped>
h1 {
    font-size: 1.2rem;
}
</style>

В качестве примера рассмотрим пошагово, как проявляется DevOps на каждом из этапов разработки, на примере написания ПО.

![height:350px center](./images/devops-plan-mem.jpeg)

---

# Шаг 1: Планирование

![bg right:50% 95%](./images/architect-mem.jpg)

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
</style>

Сначала на, основе требований бизнеса, **бизнес-аналитиком** пишутся бизнес-требования (БТ), потом **архитектура приложения** и, если она всех устраивает, то бизнес-требования перерабатываются **системным-аналитиком** в техническое задание (ТЗ).

*На этом шаге DevOps* — это какие-либо тикетные системы планирования, проджект-системы.

---

# Шаг 2: Кодинг (разработка)

![bg left:50% 95%](./images/programmer-mem.jpg)

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
</style>

**Разработчики** пишут код на основе ТЗ, результатом чего появляется некая первая версия приложения (ПО) в сыром виде.

*Здесь DevOps* — это IDE разработчиков и репозиторий исходных кодов. Важно, на данном этапе так же важно покрытия кода функциональными и unit-тестами, а так же проверка кода на код-дизайн (code-style), и code-review (ревью кода).

---

# Шаг 3: Компиляция

![bg right:50% 95%](./images/compiling-mem.jpg)

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
</style>

Скомпилированное (собранное) приложение собирается с прохождением проверок на код-дизайн, покрытие кода функциональными и unit-тестами. Если все проверки прошли успешно, то сборка приложения помещается в реестр скомпилированных приложений, или артефактов.

---

# Шаг 4: Тестирование

![bg left:50% 95%](./images/test-mem.jpeg)

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
</style>

Чтобы сборку протестировать, её нужно задеплоить или развернуть на некий тестовый контур. Это может быть выделенная тестовая **тестировщика**, виртуальная машина (ВМ) или набор тестовых контуров. После чего происходит различного рода тестирования, которое всегда начинается с мануального, а далее - smoke, функциональное, UI, регресс, нагрузочное и т.д., в зависимости от зрелости методологии тестирования в компании.

---

# Шаг 5: Формирование релиза

![bg right:50% 95%](./images/release-mem.jpeg)

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
</style>

Его могут собирать, как сами **девопс-инженеры** или **лид-разработки**, или **ответственный разработчик**, либо отдельно отведённые под это **специалисты**, которые отвечают за сам релиз. Ими могут быть - **скрам-мастера**, **delivery-manager**, **release-manager** и т.д.

---

# Шаг 6: Деплой в продакшен

![bg left:40% 100%](./images/prod-mem.jpg)

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 1rem;
}
</style>

Развёртывание нашего ранее собранного и протестированного релиза ПО в продакшен. Важно, должен быть сохранён принцип идемпотентности, та сборка, что была собрана и протестирована всеми необходимыми видами тестирования, должна попасть в продуктивный контур.

---

# Шаг 7: Мониторинг

![bg right:50% 100%](./images/monitoring-mem.jpg)

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.9rem;
}
</style>

**Разработчики** и **специалисты из подразделения поддержки** (operations) и/или **мониторинга**, наблюдаем за ранее развёрнутым релизом: насколько все прошло хорошо, нужна ли поддержка или дополнительный мониторинг.

---

# Определение термина подход

<style scoped>
h1 {
    font-size: 1.2rem;
}
</style>

[**Подход**](https://gufo.me/dict/ozhegov/подход) - это совокупность приёмов, способов.

[**Подход**](https://gufo.me/dict/ozhegov/подход) - это способ решения, осуществления, объяснения чего-либо

[**Подход**](https://didacts.ru/termin/podhod.html) - процедура, в которой при построении методов, проектов деятельности предварительно вводится "онтология", исходным основанием которой служит содержание понятия, соответствующего названию подхода.

---

# DevOps как сочетание подходов

<style scoped>
h1 {
    font-size: 1rem;
}
li {
    font-size: 0.8rem;
}
p {
    font-size: 0.8rem;
}
</style>

![bg left:35% 100%](./images/list.jpg)

- Continuous Integration (CI)
- Automated Testing (AT)
- Continuous Testing (CT)
- Continuous Deployment (CD)
- Automated Recovery (AR)
- Release Management (RM)
- Infrastructure as Code (IaС)
- Performance Monitoring (PM)
- Application Monitoring (AM)
- Business Monitoring (BM)
- Configuration Managment (CM)
- CI/CD

---

# Continuous Integration (CI)

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
</style>

**Непрерывная интеграция** — это процесс работы с исходным кодом, сборка и тестирования покрытия кода функциональными и unit-тестами, проверка кода code-style и code-review. Результатом этого подхода будет артефакт (artefact) — скомпилированное приложение.

![height:350px center](./images/ci.png)

---

# Automated Testing (AT)

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
</style>

Когда приложение переваливает за десятки или сотни версий, мануально его тестировать становится уже невыгодно и слишком медленно. Тут нам на помощь приходят **автотесты**, которые встраивают в pipeline.

![height:350px center](./images/at.png)

---

# Continuous Testing (CT)

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
</style>

Этот подход заключается в том, что полный **цикл тестирования автоматизирован**. Когда у вас зрелое приложение, зрелые процессы в компании и присутствуют все необходимые виды тестирования и код хорошо покрыт тестами.

![height:350px center](./images/ct.png)

---

# Continuous Deployment (CD)

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
</style>

Суть этого подхода — сделать конвейер, который позволит каждое успешно пройденное изменение кода **автоматически разворачивать** в рабочую среду или производственную среду без вмешательства человека. Согласно классической модели разработки у нас должно быть минимум 3 контура: тест, предпрод и прод. В зависимости от проекта и наличия видов тестирования, добавляются другие варианты контуров.

![height:250px center](./images/cd.png)

---

# Automated Recovery (AR)

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
</style>

Это подход, при котором можно **восстанавливать любой контур**, прежде всего, контур продакшна на предыдущую версию приложения со всеми вытекающими, как слой app, так и слой DB. Некоторые приложения не умеют автоматически откатываться на предыдущую версию. Даже если такой конвейер настроен из коробки с учетом CI/CD инструментов. Соответственно, некоторые приложения фиксят свои баги только путём доустановкой следующего релиза. Они не могут откатиться назад, могут идти только докатками.

![height:200px center](./images/ar.png)

---

# Release Management (RM)

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
</style>

Это **управление релизным циклом** всего приложения, а не каких-то отдельных элементов или сервисов. Основная задача релиз менеджмента — планировать релизы сроки поставки ПО, а так же весь его релизный цикл, в который входит понимание вхождения количества задач в релиз и их функционал. DevOps-инженер не всегда напрямую управляет в релиз-менеджменте, но в самом цикле он участвует.

![height:300px center](./images/rm.png)

---

# Infrastructure as Code (IaС)

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
</style>

Подход заключается в том, что через репозиторий исходного **кода** можно полностью уметь **управлять вашей инфраструктурой**. То есть CD — это установка приложений на какой-то контур, а здесь мы и сам контур можем развернуть с нуля одной кнопкой. Начиная с ВМ, заканчивая ОС и всеми настройками, зависимостями компонентов приложений, конфигурациями, переменными окружения.

![height:300px center](./images/iac.png)

---

# Performance Monitoring (PM)

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
</style>

Основная суть подхода в том, что у нас должен быть только тот **мониторинг**, который необходим на всех слоях. Если у нас какая нибудь виртуализация, нам нужно мониторить гипервизор, железо, мы должны мониторить конкретную виртуальную машину по CPU, memory и т.д.

![height:250px center](./images/pm.png)

---

# Application Monitoring (AM)

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
</style>

Это история про **поведение приложения**, в которую входят его **метрики**: connection treadpool, connection db pool, расходование именно самим приложением памяти, нагрузку на утилизацию ядер, попадание в SWAP, деградация свершения запросов в БД и т.д. Слой app затрагивает все компоненты приложения. Не забываем, что сюда входит не только классический app мониторинг, но и log-tracing.

![height:250px center](./images/am.png)

---

# Business Monitoring (BM)

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
</style>

Это **мониторинг** фактического получения прибыли вашей компании, то есть **бизнес-операций**. Если мы покупаем какую-нибудь страховку, то это значит регистрация пользователя, калькуляция страховки, работа с регуляторами. Это важно, потому что на базе этого мониторинга вы можете прогнозировать и наблюдать за реальным количеством продаж, как на перспективу времени, так и анализировать ретроспективу.

![height:250px center](./images/bm.png)

---

# Configuration Managment (CM)

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
</style>

Это **управление конфигурациями**, причём, не только контуров, но и самого ПО. Конфигурации должны быть обвешены автоматизацией и управляться через неё. Речь идет о конфигах серверов ПО, конфигах логирования и мониторинга, интеграционных, авторизации, кеш и так далее. Всем этим нужно уметь управлять через код, через систему управления и развертывания.

![height:250px center](./images/cm.png)

---

# CI/CD

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
</style>

Это **конвейер**. Допустим у нас есть: код, коммиты, релизы, сборки, проверка кода тестами, интеграционные тесты, итоговое ревью, состав релиза, нагрузочное тестирование и развертывание на конечный продакшн.

![height:350px center](./images/cicd.png)

---

# Continuous Delivery и Continuous Deployment

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
</style>

**Continuous Deployment** — это полностью автоматизированный цикл, когда автоматически происходит раскатка в продакшн. Причем она может быть по расписанию.

![height:350px center](./images/continuous-delivery-continuous-deployment.png)

---

# Определение термина технология

<style scoped>
h1 {
    font-size: 1.2rem;
}
p {
    font-size: 0.9rem;
}
</style>

[**Технология**](https://science_philosophy.academic.ru/403/ТЕХНОЛОГИЯ) - (от греч. искусство, мастерство, умение и греч. изучение) – совокупность  методов и  инструментов для  достижения желаемого результата; метод  преобразования данного  в  необходимое;  способ  производства.

[**Технология**](https://dic.academic.ru/dic.nsf/fin_enc/30425) - *в широком смысле* - объем знаний, которые можно использовать для производства товаров и услуг из экономических ресурсов.

[**Технология**](https://dic.academic.ru/dic.nsf/fin_enc/30425) - *в узком смысле* - способ преобразования вещества, энергии, информации в процессе изготовления продукции, обработки и переработки материалов, сборки готовых изделий, контроля качества, управления.

---

# DevOps как сочетание технологии

<style scoped>
h1 {
    font-size: 1.2rem;
}
li {
    font-size: 1rem;
}
p {
    font-size: 1rem;
}
</style>

![bg left:45% 101%](./images/technologies-mem.jpg)

Ключевые инструменты, без которых внедрить подход DevOps нельзя:

- Системы контроля версий;
- CI/CD-системы;
- Системы мониторинга.

---

# Как мы дошли до всего этого?

![height:450px center](./images/evolve-devops.png)

---

# Что было до DevOps

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
</style>

![bg left:50% 95%](./images/waterfall.jpg)

C 1970-ых годов  каскадная модель процесса разработки программного обеспечения, известная как **Waterfall**. Методика предполагала последовательный переход между этапами без пропусков и возвращений на предыдущие стадии.

Со временем была раскритикована за недостаточную гибкость, а ее основная цель – формальное управление проектом, **приносила ущерб** срокам, стоимости и качеству.

---

# Гибкие методики разработки

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
</style>

**Гибкие методики разработки** (agile software development) — обобщающий термин для целого ряда подходов и практик, основанных на ценностях Манифеста гибкой разработки программного обеспечения и 12 принципах, лежащих в его основе.

![height:400px center](./images/agile.png)

---

# Agile-манифест

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
</style>

**Agile-манифест** увидел свет в феврале 2001 года в городе Сноуберд (США). Тогда встретились 17 экспертов и практиков в области разработки ПО. Они поставили цель — создать метод, который позволит эффективно справляться с вызовами и изменениями IT-индустрии. Среди участников были представители различных методологических школ: экстремального программирования (XP), Scrum, DSDM и других.

![height:300px center](./images/agile-manifest-persons.png)

---

# Принципы и ценности Agile-манифеста

<style scoped>
h1 {
    font-size: 1.1rem;
}
p {
    font-size: 0.9rem;
}
</style>

По Agile, **люди важнее** процессов и инструментов. Нельзя следовать жестким правилам, если это мешает взаимодействию сотрудников и продуктивной работе.

**Приоритет методологии** — жизнеспособный продукт, а не документация. Лучше сделать то, что работает, чем тратить ресурсы на отчетность.

Еще одна ценность — **сотрудничество с заказчиком**. Работайте с клиентом напрямую, чтобы понимать его потребности.

По Agile, **готовность к изменениям важнее** следования первоначальному плану. Всегда будьте готовы к смене курса и научите команду быстро перестраиваться.

---

# Фреймворки Agile

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
li {
    font-size: 0.8rem;
}
</style>

- **Scrum**. Фреймворк управления проектами по Agile, ориентированный на итеративное и инкрементное создание продукта. Подход определяет роли, события и артефакты, которые делают процесс более гибким и прозрачным.
- **Канбан**. Метод управления, в основе которого — визуализация потока работы. Команда заполняет Kanban-доску, на которой отражается текущее состояние каждой задачи: от идеи до завершения. Все в курсе, какие процессы в работе, что только предстоит сделать, а какие цели уже достигнуты.
- **Экстремальное программирование** (XP). Акцент на практиках, которые повышают качество кода, автоматизируют тестирование и обеспечивают частую поставку работающего продукта.
- **Lean Software Development**. Производное от методов Toyota Production System. Здесь акцент на минимизации потерь и обосновании ценности для клиента.

---

- **SAFe** (Scaled Agile Framework). Набор инструментов для внедрения аджайл-практик в больших компаниях. SAFe помогает множеству команд работать в рамках Agile, сохраняя координацию и высокий темп выполнения задач. Это как управление маленькими лодками в большом океане: каждое судно (agile-команда) движется своим путем, но все равно остается частью большой системы.
- **LeSS** (Large Scale Scrum). Подход к масштабированию Scrum, более простой, чем SAFe. Вместо множества процессов и дополнительных ролей LeSS стремится к минимальной этапности и отсутствию иерархии.

---

# Критика Agile

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
</style>

![bg right:45% 95%](./images/agile-criticism.jpg)

Методология Agile критиковали за отсутствие **управления требованиями**. Заказчик может выставить новые требования в конце каждой итерации, что противоречит архитектуре уже созданного продукта.

Частые изменения и усовершенствования продукта могут привести к массовому **рефакторингу** и **плавающей стоимости проекта** в итоге.

При этом Agile не рассматривает **инструменты** разработки.

---

# Идея и культура DevOps

Методология DevOps получила широкое распространение после организованной бельгийским разработчиком Патриком Дебуа в 2009 году конференции DevOpsDays.

Главная идея DevOps заключается в том, чтобы **устранить перекладывание ответственности** на других членов команды в больших коллективах. Взаимозависимость между созданием и эксплуатацией программного обеспечения преследовала цель **привить команде новую культуру разработки продукта**.

---

# Принципы DevOps

<style scoped>
h1 {
    font-size: 1.2rem;
}
p {
    font-size: 0.9rem;
}
li {
    font-size: 0.9rem;
}
</style>

В 2010 году Дэймоном Эдвардсом и Джоном Уиллисом была разработана модель CAMS, ключевые идеи которой стали принципами DevOps. Согласно ей, развитие DevOps идет в трех направлениях: **люди**, **процессы** и **инструменты**. При этом важна поддержка каждого пункта на всех этапах развития.

Аббревиатура CAMS расшифровывается следующим образом:

- культура (culture);
- автоматизация (automation);
- измерение (measurement);
- обмен (sharing).

---

# CAMS: Культура

<style scoped>
h1 {
    font-size: 1.2rem;
}
</style>

Классические бизнес-модели в IT разделяют специалистов по разработке и эксплуатации на две отдельные группы.

Конкурирующие рабочие цели создавали между специалистами по разработке и эксплуатации недопонимание, поэтому основная задача DevOps – изменить бизнес-культуру, **разделить ответственность двух групп и объединить их профессиональные навыки**.

---

# CAMS: Автоматизация

<style scoped>
h1 {
    font-size: 1.2rem;
}
</style>

В идеале автоматизировать нужно почти все:

- инфраструктуру;
- выпуски программного обеспечения (software releases);
- тестирование;
- развертывание;
- основные задачи по безопасности;
- политику соглашений;
- задачи управления конфигурацией.

---

# CAMS: Измерение

<style scoped>
h1 {
    font-size: 1.2rem;
}
</style>

Измерять нужно показатели следующих процессов:

- мониторинга и отслеживания производительности на протяжении всего жизненного цикла разработки программного обеспечения;
- сбора, анализа и предоставления способов реагирования на обратную связь;
- анализа ошибок и способов их предотвращения;
- оказания помощи командам в работе над общими целями.

---

# CAMS: Обмен

<style scoped>
h1 {
    font-size: 1.2rem;
}
p {
    font-size: 0.9rem;
}
</style>

![bg left:45% 95%](./images/tester-programmer-mem.jpeg)

DevOps подразумевает **тесное сотрудничество специалистов по разработке и эксплуатации**. Большое внимание уделяется прозрачности и открытости в коллективе. Чем больше знаний распространяется между сотрудниками, тем больше обратной связи они получают – это помогает улучшить их работу в целом.

---

# DevOps и Agile

<style scoped>
h1 {
    font-size: 1.2rem;
}
p {
    font-size: 0.9rem;
}
</style>

DevOps является **естественным продолжением** гибких подходов и подходов к непрерывной доставке. DevOps и Agile могут **дополнять друг друга** и **применяться в тандеме**, но сравнивать эти методологии не стоит.

![height:350px center](./images/devops-agile.jpg)

---

<style scoped>
li {
    font-size: 0.9rem;
}
p {
    font-size: 0.9rem;
}
</style>

![bg right:45% 95%](./images/deploy-mem.png)

Основные различия между DevOps и Agile:

- Разработка, тестирование и развертывание программного обеспечения происходят как в DevOps, так и в Agile. Подход Agile характерен тем, что **разработка завершается сразу после развертывания**. DevOps же включает операции, которые происходят **постоянно**, например, мониторинг и модификации программного обеспечения;

---

- В Agile **разные специалисты несут ответственность** за разработку, тестирование и развертывание программного обеспечения. В DevOps за все эти процессы отвечают специально обученные инженеры;

![height:350px center](./images/agile-need-more-mem.png)

---

![bg left:45% 95%](./images/agile-kanban-waterflow-mem.jpg)

- Agile выступает за **поэтапное развертывание** после каждого спринта. Для DevOps характерна **непрерывная доставка** (до нескольких раз в день).

---

# В результате имеем

<style scoped>
h1 {
    font-size: 1rem;
}
p {
    font-size: 0.8rem;
}
</style>

В итоге ни Agile, ни DevOps как таковые **не являются целью бизнеса**. Эти подходы — культурные движения, предоставляющие организации лучшие средства для достижения целей.

Для большей эффективности Agile и DevOps лучше сочетать, а не противопоставлять. Чтобы избежать конфронтации между этими двумя идеями, **нужно понять глубинные ценности и принципы**, на которых они основаны. Лежащие на поверхности, но узкие определения ведут к **разобщенному мышлению**.

> В современном мире каждый понимает терминологию, которую рассмотрим далее, по своему, не смотря на множество трудов и устоявшихся терминов. Это не мешает людям понимать, что такое DevOps, по своему.

---

# Использованные источники

<style scoped>
h1 {
    font-size: 1rem;
}
li {
    font-size: 0.8rem;
}
</style>

1. [DevOps: методология, принципы, подходы и технологии](https://habr.com/ru/articles/745532/)
2. [Разница между Agile и DevOps](https://otus.ru/journal/raznica-mezhdu-agile-i-devops/)
3. [Agile и DevOps методологии в тестировании ПО](https://test-planet.by/news/agile-i-devops-metodologii-v-testirovanii-po/)
4. [Как взаимосвязаны Agile и DevOps?](https://www.atlassian.com/ru/agile/devops)
5. [Agile, DevOps, CI/CD. Как менялись концепции разработки](https://itentika.ru/blog/agile-devops/)
6. [Основы методологии DevOps](https://proglib.io/p/osnovy-metodologii-devops-2021-02-20)
7. [The 13-Types Of Ops](https://www.forbes.com/sites/adrianbridgwater/2023/08/18/the-13-types-of-ops/?sh=76e4efe04b5a)
8. [The Many Flavors of Ops](https://dzone.com/articles/the-many-flavors-of-ops)
9. [Что такое DevOps: зачем он нужен, где применяется и в чём его плюсы и минусы](https://practicum.yandex.ru/blog/chto-takoe-tehnologiya-devops/)
10. [AT THE HEART OF DEVOPS LIES CONFLICT](https://www.eficode.com/blog/at-the-heart-of-devops-lies-conflict)

---

<style scoped>
h1 {
    font-size: 1rem;
}
li {
    font-size: 0.8rem;
}
</style>

11. [Люди и конфликты в DevOps // Ахмед Шериев, независимый эксперт по DevOps](https://youtu.be/OizjZIr-CLk)
12. [Пора закончить холодную войну между DevOps и разработчиками ПО](https://habr.com/ru/companies/ruvds/articles/702514/)
13. [Agile-манифест: ключевые положения, принципы, история и развитие](https://www.bitrix24.ru/journal/agile-manifesto/)

---

# Вопросы?

<style scoped>
p {
  text-align: center;
}
</style>

![height:430px center](../images/questions.jpg)

**If not, just clap your hands!**
